fix: pass arrow keys through in normal and visual mode - #66
Merged
Conversation
handleNormalKey and handleVisualKey ended with a catch-all that consumes any unbound key. Arrow keys aren't vim motions (only hjkl are), so they hit that catch-all and were swallowed, and the intercept then called ctx.consume(), so OpenCode never received the key. In the subagent view that trapped users (issue #63): after Esc to enter normal mode, arrow_up did nothing, and the only way out was the non-obvious workaround of pressing i to re-enter insert mode, where arrows already passed through. Return PASS for up/down/left/right in both handlers so the host handles them (move the cursor in the prompt, exit the subagent view, etc.), now consistent with insert mode. In visual mode arrows move the cursor via the host rather than extending the selection; extending on arrows can be a follow-up. Fixes #63
5 tasks
oribarilan
added a commit
that referenced
this pull request
Sep 2, 2026
Patch release for the #63 fix (already merged via #66). ### Fixed - Arrow keys no longer get swallowed in normal and visual mode. They pass through to OpenCode, so you can exit the subagent view (and use other native navigation) without first switching to insert mode ([#63](#63)). ### Release checklist - [x] Moved `[Unreleased]` into `## [0.17.1]` and updated CHANGELOG link refs - [x] Bumped `package.json` to 0.17.1 - [x] Bumped `VERSION` in `src/version.ts` to match - [x] Updated README install/config version tags to v0.17.1 - [x] `just check` green (222 tests) Tag `v0.17.1` and the GitHub release follow after this merges.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
In normal and visual mode, arrow keys (up/down/left/right) now pass through to OpenCode instead of being swallowed by the vim intercept.
Why
handleNormalKeyandhandleVisualKeyend with a catch-all that consumes any unbound key. Arrow keys aren't vim motions (onlyhjklare), so they hit that catch-all and were consumed with no action. The intercept then calledctx.consume(), so OpenCode never saw the key.That trapped users in the subagent view (#63): after pressing
Escto enter normal mode,arrow_updid nothing, and the only way out was the non-obvious workaround of pressingito re-enter insert mode (where arrows already passed through).How
Return
PASSfor up/down/left/right in both handlers, before the catch-all. Insert mode already passed them through, so behavior is now consistent across modes. In the prompt they do the host's default (move the cursor); in views like the subagent view they drive native navigation.Note: in visual mode arrows move the cursor via the host rather than extending the selection like
hjkl. That keeps the fix simple and avoids trapping keys. Extending selection on arrows can be a follow-up.Tests
PASS(not consumed, no actions).plugin.tuito the key intercept) and asserts the intercept does not consume arrows, with a control that a vim motion (j) still is.just checkis green (222 tests).Fixes #63